1. Field
Embodiments of the present invention relate generally to computer programming, game design and computational thinking. More particularly, embodiments of the present invention relate to methods of providing rich semantic feedback to programmers by evaluating rules in a behavior editor responsive to hypothetical situations and/or executing programs, or parts of programs, in data contexts relevant to the programmer.
2. Description of the Related Art
Programming is generally considered a difficult intellectual pursuit. The notion of programming precedes modern computers, but computers are the main devices used to design, build and maintain programs. Computers have not only steadily become more powerful from a mere computational cycles point of view, but over time they have also introduced and improved new affordances relevant to programming, such as computer graphics, often used in visual programming, or new kinds of interface devices, such as the mouse, to enable more effective means of program composition, such as drag and drop interfaces. Naturally, most of these efforts have focused on the most urgent problems in programming. Especially syntactic concerns have, in the early days of programming, and still today represented a difficult obstacle to overcome for beginning programmers.
FIG. 1 conceptually illustrates the highly asymmetrical conversation between a programmer 100 and a programming environment 130 in the context of traditional programming. Communication between programmer 100 and programming environment 130 is typically highly asymmetrical and limited to syntactic feedback 110 of limited usefulness. Syntactic feedback 110 is limited in nature to programs (e.g., program 140) that are malformed. If one excludes one semicolon in a C program, the program may not work at all. Over time, programming environments (e.g., programming environment 130) have improved by integrating a number of tools that seek to help reduce problems stemming from syntactic issues. However, even modern integrated programming environments, such as Eclipse, Xcode or Visual Studio largely follow the model of FIG. 1 by providing a highly asymmetrical conversation of limited usefulness.
This highly asymmetrical conversation is based on a long history of programming research and represents a crucial step in the right direction. Some of the first programming environments hardly included any kind of meaningful feedback turning the process of programming into a monologue. For example, early programmers had to enter a complete program without any kind of syntactic feedback. Then, when trying to run or compile the program, the programmer would see that the program did not work or, in the best case scenario, get some error message from the compiler. The main problem with such programming was recognized early on. Researchers trying to create programming environments then created systems that would provide earlier and more meaningful feedback. By 1967, the Dialog system employed input/output devices that were many years ahead of its time and provided almost instant feedback to the programmer after each character was input in a way similar to modern symbol completion found in Integrated Development Environments such as the symbol completion on Lisp machines, or intellisense of Visual Studio and similar environments including Eclipse, and Xcode. All of these environments analyze text input and help the programmer by either popping up valid completion menus or a constrained set of characters and symbols on a virtual keyboard.
A very different approach but with similar results can be found in the field of visual programming. Instead of typing in text-based instructions many visual programming languages are based on the composition of programs from basic components using mechanisms such as drag and drop. Similar to symbol completion approaches, these kinds of visual programming environments essentially attempt to prevent syntactic programming mistakes based on typos. Systems, such as AgentSheets, provide dynamic drag and drop feedback to indicate compatibility/incompatibility of some programming language building blocks while the user is trying to drag them onto targets. Other approaches experiment with puzzle piece shaped programming language building blocks to convey compatibility. More recent systems aimed at end-users, such as Scratch, use similar approaches.
While these approaches have significantly reduced syntactic problems they largely ignore the much more problematic notion of semantic feedback. The fact that a programming environment 130 provides the necessary syntactic feedback 110 (responsive to the programmer 100 editing the program 120) to help the programmer 100 create a syntactically correct program does not imply that the resulting program is meaningful or even runs at all. The asymmetry of the conversation between programmer 100 and programming environment 130 in FIG. 1 is not only intended to indicate the amount of information flowing each way but also the degree of usefulness to create a program that works and is meaningful.
Semantics is about the meaning of a program, which of course is very important. Unfortunately, existing semantic analysis is limited in usefulness because it usually separates programs from data and therefore removes important context necessary to provide truly useful feedback to the programmer. For instance, semantic analysis can reveal that a function is called with the wrong number of kind or parameters. The true meaning of calling a function with actual parameters can only be experienced when actually calling that function. Is a certain condition true, will a certain function return the right value? These kinds of questions require a deep dynamic approach including data in the analysis of semantics.